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Die f olgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Priifungsantrag gem. § 44 PatG ist gestellt 

(g) Verfahren und Kommunikationssystem zum Verwalten eines Kommunikationsnetzes 

® Die Erfmdung betrifft ein Verfahren zum Verwalten ei- 
nes Kommunikationsnetzes mit zumindest einer uberge- 
ordneten funktionalen, hersteller-unabhangigen Einrich- 
tung (NMC) und zumindest einer davon uberwachten 
und/oder gesteuerten untergeordneten Einrichtung 
(OMC), zwischen denen Nachrichten uber den Zustand 
zumindest einer nicht funktionalen, hersteller-abhangi- 
gen Einrichtung (OMC, BSC, BTSE,TRAU) des Kommuni- 
kationsnetzes ausgetauscht werden. 

Um in Kommunikationsnetzen eine automatische Test- 
Funktionalitat von einem ubergeordneten hersteller-un- 
abhangig verwaltenden Netzmanagementzentrum (NMC) 
aus zu ermoglichen, beispielsweise zu Zeiten, an denen 
untergeordnete, herstellerspezifische Betriebs- und War- 
tungszentren (OMC) nicht besetzt sind, wird vorgeschla- 
■ gen, beim Austausch einer Alarm-Nachricht zumindest 
- eine hersteller-abhangige Information zu ubermitteln und 
t am Netzmanagementzentrum hersteller-spezifische 
Hardware-Tests automatisch zu erzeugen. Dabei muS das 
Informations-Modell der OMC-NMC-Schnittstelle keine 
hersteller-spezifische Objektklassen kennen. 
Die am Netzmanagementzentrum NMC automatisch ge- 
nerierten Tests konnen sowohl dediziert, also z. B. nach 
dem Auftreten von Fehlern eines bestimmten Hardware- 
Board als auch praventiv, z. B. fur die gesamte Hardware 
einer Netzeinheit, getriggert werden. 
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Beschreibung 

Die Erfindung betrifft ein Verfahren zum Verwalten eines 
Kommunikationsnetzes, insbesondere zum Erzeugen von 
Tests an einem ubergeordneten Netzmanagementzentrum 5 
bzw. ein Kommunikationssystem zum Duichfiihren des Ver- 
fahrens. 

In Funk-Konimunikationssystemen werden Inform atio- 
nen (beispielsweise Sprache, Bildinformationen, oder an- 
dere Daten) mit Hilfe von elektromagnetischen Wellen iiber 10 
eine Funkschnittstelle zwischen sendender und empfangen- 
der Funkstation (Basisstation bzw. Mobilstation) ubertra- 
gen. Das Abstrahlen der elektromagnetischen Wellen erfolgt 
dabei mit Tragerfrequenzen, die in dem fur das jeweilige Sy- 
stem vorgesehenen Frequenzband liegen. Beim GSM (Glo- 15 
bal System for Mobile Communication) liegen die Irager- 
frequenzen im Bereich von 9(X), 1800 bzw. 1900 MHz. Fur 
zukiinftige Mobilfunknetze mit CDMA- oder TD/CDMA- 
Ubertragungsverfahren iiber die Funkschnittstelle, bei- 
spielsweise das UMTS (Universal Mobile Telecommunica- 20 
tion System) oder andere Systeme der 3. Generation sind 
Frequenzen im Frequenzband von ca. 2000 MHz vorgese- 
hen. 

Die Prinzipien eines allgemeinen Managementaetzes, die 
auch als TMN-Prinzipien (TMN: Telecommunications Ma- 25 
nagement Network) bezeichnet werden, definieren mehrere 
Managementebenen fiir das Management eines Kommuni- 
kationssystems - beispielsweise eines Mobil-Kommunikati- 
onssystems -, wobei jede Ebene eine doppelte Funktion hat. 
Im managenden System hat jede Ebene auBer der untersten 30 
eine Managerfunktion fur die darunterliegende Ebene. Im 
gemanagten System hat jede Ebene auBer der obersten eine 
Agentenfunktion fur die nachst hohere Ebene. 

In einer objekt-orientierten Umgebung gibt es eine Viel- 
zahl von Objekten, die Netzressources mit jeweils einer be- 35 
stimmten Funktionalitat darstellen. Bei der objekt-orientier- 
ten Umgebung, wie sie typischerweise zwischen Manager 
und Agent in einem Mobilfunknetz besteht, wird entspre- 
chend jede Agent-Funktionalitat von einem bestimmten Ob- 
jekt bereitgestellt, das als gemanagtes Objekt (bzw. Objekt- 40 
instanz MOI) einer Objektklasse verfugbar ist. 

Das Objekt entsteht als Ergebnis einer Modellierungs-Ta- 
tigkeit, bei der neben der Funktionalitat u. a. die Parameter 
und Rahmenbedingungen definiert werden, und ist sowohl 
dem Manager als auch dem ausfuhrenden Agent an der ent- 45 
sprechenden Schnittstelle bekannt. Die Schnittstelle kann 
z. B. bei einem Mobilfunknetz die sogenannte O-Schnitt- 
stelle zwischen einem Betriebs- und Wartungszentrum 
(OMC in Fig, 1) und einem Basisstationssystem (BSS) sein. 

Eine Objektinstanz einer bestimmten gemanagten KLasse 50 
A, die auch als managed object class bezeichnet wird, kann 
weitere Objektinstanzen derselben oder anderer Klassen 
enthalten. Eine solche Beziehung zwischen Objektinstanzen 
- nicht Klassen - wird in der Modellierung auch als Ein- 
schlieBungsbeziehung bzw. "containment relationship" be- 55 
zeichnet. 

Eine Beziehung zwischen Objektklassen, die spezifiziert, 
daB eine Objektinstanz einer Klasse als ubergeordnetes (SU- 
PERIOR) Objekt fur Objekte einer anderen Klasse definiert 
ist oder definiert sein kann, wird auch als Bezeichnungsbin- 60 
dung bzw. "NAME BINDING" bezeichnet. Eine hierarchi- 
sche Zuordnung von Objekten, in der die Hierarchie auf 
Grundlage von NAME-BINDING-Beziehungen organisiert 
ist, wird allgemein als Bezeichnungsbaum bzw. "naming 
tree" bezeichnet. 65 

In einem Telekommunikationsnetz, z. B. einem Mobil- 
funknetz, erfolgt die Netziiberwachung und -kontrolle dabei 
ublicherweise von zwei Managerseiten aus: einerseits zen- 



877 A 1 

2 

tral von einem Betriebs- und Wartungszentrum OMC aus 
(OMC: Operation and Maintenance Centre), was einem Ele- 
ment-Manager entspricht, und andererseits vor Ort von einer 
lokalen Wartungs-Datenendstation LMT aus (LMT Local 
Maintenance Terminal), die an verschiedenen Netzeinheiten 
angeschlossen werden kann. Solche Netzeinheiten sind in 
einem Mobilfunknetz beispielsweise ein Basisstations-Un- 
tersystem BSC, eine Basisstations-Empfanger-/Sendersta- 
tion BTSE (BTSE: Base Transceiver Station Equipment), 
die die dortige Hardware modelliert bzw. beriicksichtigt, 
oder eine Transcoder- und Raten-Adaptereinheit TRAU. 

Ein gesamtes, von einem Diensteanbieter gemanagtes Te- 
lekommunikationsnetz wird aus betrieblicher Sicht in meh- 
rere Netzregionen unterteilt, wie dies auch aus Fig. 1 er- 
sichtlich ist. Obwohl das gesamte Netz Hardware von ver- 
schiedenen Herstellern enthalt, werden innerhalb jeder die- 
ser Netzregionen sowohl die Netzelemente, als auch die vor- 
stehend aufgefuhrten Managementsysteme ublicherweise 
vom gleichen Hersteller geliefert, da das Management am 
Betriebs- und Wartungszentrum OMC und an lokalen War- 
tungs-Datenendstationen alle hersteller- spezifischen Eigen- 
schaften der Hardware berucksichtigen muB. Dazu gehoren 
insbesondere auch die Tests der Funktionalitat einzelner 
Komponenten. 

Wahrend der Nacht, der Feiertagen und am Wochenende 
wird das Mobilfunknetz einerseits von einem ubergeordne- 
ten Netzmanagementzentrum uberwacht, das ublicherweise 
als "Network Management Centre" (NMC) bezeichnet wird, 
da die regionalen Betriebs- und Wartungszentren OMCs zu 
diesen Zeiten unbesetzt sind. Anderseits muB die Schnitt- 
stelle zwischen dem Netzmanagementzentrum NMC und 
den regionalen Betriebs- und Wartungszentren OMCs her- 
steller- unabhangig bleiben, um eine funktionale Integration 
herstellerspezifischer Netzregionen unter einem einheitli- 
chen Netzmanagementzentrum NMC zu ermoglichen. 

Diese Herstellerunabhangigkeit der OMC-NMC- Schnitt- 
stelle kann in einer objekt-orientierten Managementumge- 
bung durch die exklusive Verwendung sogenannter funktio- 
naler Objektklassen, insbesondere Management-Objekt- 
klassen (functional-related MOQ erfolgen. Die funktiona- 
len Objekte modellieren dabei die Netzressourcen eines Te- 
lekommunikationsnetzes aus einer funktionalen, hersteller- 
unabhangigen Sicht. Im Gegensatz dazu kennt die herstel- 
ler-spezifische Schnittstelle zwischen Betriebs- und War- 
tungszentrum OMC und den Netzelementenauch soge- 
nannte hardware-bezogene Management-Objektklassen 
(equipment-related MOC), die von Hersteller zu Hersteller 
unterschiedlich sind. Netzelemente sind dabei z. B. die Ba- 
sisstationen BSS, die in einer Netzregion von einem OMC 
gemanaged werden. 

Um auf unvorhersehbare Ereignisse, z. B. einen Ausfall 
von bestimmten Hardwarekomponenten, rasch reagieren zu 
konnen, muB der Operator des Netzmanagementzentrums 
NMC in der Lage sein, entsprechende Tests zu starten. Al- 
lerdings haben die Operatoren des Netzmanagementzen- 
trums im Unterschied zu Operatoren der Betriebs- und War- 
tungszentren OMC keine systemspezifische Kenntnisse 
iiber die Hardware eines bestimmten Herstellers. Dadurch 
konnen keine hersteller-spezifischen Tests durchgefuhrt 
werden. 

Die Aufgabe der Erfindung besteht darin, ein verbessertes 
Verfahren zum Verwalten eines Kommunikationsnetzes vor- 
zuschlagen, insbesondere in Kommunikationsnetzen eine 
automatische Test-Funktionalitat von einem iibergeordne- 
ten, hersteller-unabhangigen Netzmanagementzentrum aus 
zu ermoglichen. 

Diese Aufgabe wird durch das Verfahren mit den Merk- 
malen des Anspruchs 1 und das Funk-Kommunikationssy- 
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stem mit den Merkmalen des Anspruchs 13 gelost. Vorteil- 
hafte Weiterbildungen sind Gegenstand von Unteransprii- 
chen. 

Der Konflikt zwischen der Handhabung von einerseits 
hersteller-unabhangigen funktionalen Management-Objekt- 
klassen und andererseits hersteller-spezifischen, hardware- 
bezogenen Management-Objektklassen wird dadurch ge- 
lost, daB am Netzmanagementzentrum hersteller-spezifische 
Hardware-Tests automatisch erzeugt werden. Dies erfolgt 
vorzugsweise sowohl gezielt, d. h. nach Empfang von Alar- 
men als Folge von Hardwarefehlern, als auch generisch, 
d. h. als periodische preventive MaBnahme. 

Somit ist die automatische Erzeugung von hersteller-spe- 
zifischen Hardwaretests von einem Netzmanagementzen- 
trum NMC aus moglich, obwohl das Informations-Modell 
der OMC-NMC-Schnittstelle keine hersteller-spezifische 
Objektklassen kennt. 

Die am Netzmanagementzentrum NMC automatisch ge- 
nerierten Tests konnen sowohl dediziert, also z. B. nach dem 
Auftreten von Fehlern eines bestimmten Hardware-Board, 
als auch praventiv, z. B. fur die gesamte Hardware einer 
Netzeinheit, getriggert werden. 

Nachfolgend wird ein Ausfuhrungsbeispiel anhand der 
Zeichnung naher erlautert. Es zeigen: 

Fig, 1 ein ubliches, in mehrere Netzregionen unterteiltes 
Kommunikationsnetz, 

Fig. 2 schematisch den Ablauf einer Alarmubertragungs- 
prozedur in einem solchen Kommunikadonsnetz und 

Fig. 3 schemadsch den Ablauf hersteller-spezifischer 
Tests in einem solchen Kommunikadonsnetz. 

Beispielhafte Verfahrensablaufe zum hardwarespezifi- 
schen Testen von Netzeinrichtungen vom Netzmanagement- 
zentrum NMC aus sind in den Fig, 2 und 3 dargestellt. 

Zur Steuerung der Schnittstellen zwischen Netzmanage- 
mentzentrum NMC und den regionalen Betriebs- und War- 
tungszentren OMCs gibt es verschiedene Management-Ob- 
jektklassen MOCs. Da diese Schnittstellen hersteller-unab- 
hangig sein mussen, enthalt das Informations-Modell einer 
solchen Management-Schnittstelle nur funktionale Manage- 
ment-Objektklassen MOCs. 

Um in diesem Informations-Modell eine hersteller-spezi- 
fische Hardware zu integrieren, werden vorzugsweise die 
gesamten Hard ware-B augruppen , d. h. alle sogenannten Bo- 
ards, auf der Ebene einer Netzeinheit als eine generische 
Gesamtausstattungs-Management-Objektklasse MOC 
(equipment summary MOC) definiert. 

Zum Beispiel werden fur den Radioteil eines Mobilfunk- 
Netzes, das aus den Netzeinheiten Basisstations-Steuerein- 
richtung BSC, Basisstations-Empfanger-/Senderstation 
BTSE und Transcoder- und Raten-Adaptereinheit TRAU 
besteht, foigende Gesauitausstattungs-Management-Objekt- 
klassen MOC definiert: 

bscEquipment 
btsEquipment 
trauEquipment 

Die Management-Objektklasse bscEquipment betrifft die 
Ausstattungsmerkmale der Basisstations-Steuereinrichtung, 
btsEquipment betrifft die Ausstattungsmerkmale der Basis- 
stations-Empfanger-/Senderstation und trauEquipment be- 
trifft die Ausstattungsmerkmale der Transcoder- und Raten- 
Adaptereinheit. 

Beim Auftreten eines Hardwarefehlers in einer spezifi- 
schen Hardware-Baugruppe, z. B. bei Fig. 2 in einem Board 
1 vom Typ TPU (TPU: Transceiver Power Unit), wobei dies 
nur als ein Beispiel eines Hardware-Boards zu sehen ist, in 
Gestell- bzw. Rack-Nr. 2 der BTSE-Einheit 8, generiert 



diese Netzeinheit eine Alarm-Notification bzw. Alarm-Be- 
nachrichtigung mit den Parametern: 

- Objektklasse MOC: TPU (hardware-bezogene MOC 
5 an der hersteller-spezifischen OMC-BSS-Schnittstelle) 

und 

- Objektinstanz MOI: . . . -8-2-1 (Folge von relativ 
unterscheidbaren Namen, sogenannten Relative Distin- 
guished Names, gemaB dem Bezeichnungsbaum). 

10 

Diese Benachrichtigung wird als hersteller-spezifische 
Alarmmeldung (alarm report) uber die Netzeinheit Basissta- 
tions-Steuereinrichtung BSC an das regionale Betriebs- und 
Wartungszentrum OMC weitergeieitet. 

15 Um die Netzuberwachung an einem ubergeordneten 
Netzmanagementzentrum NMC wahrend der Zeit mit unbe- 
setzten Betriebs- und Warning szentren OMCs zu ermogli- 
chen, erhalt jedes hersteller-spezifische Betriebs- und War- 
tungszentrum OMC eine sogenannte Mediationsfunktion. 

20 Die Mediationsfunktion wandelt alle fiir das Netzmanage- 
mentzentrum NMC relevanten Ereignismeldungen (event 
reports) aus dem Telekommunikationsnetz auf die jeweils 
entsprechende funktionale Management-Objektklasse um, 
und zwar gemaB dem Informations-Modell der OMC-NMC- 

25 Schnittstelle. Diese Vorgehensweise wird auch als soge- 
nannte Abbildungs- bzw. Mapping-Prozedur bezeichnet und 
ist in Fig. 2 skizziert. 

Mit anderen Worten, Alarmmeldungen nach Hardware- 
Fehlern, d. h. hardware-bezogene, hersteller-spezifische 

30 Alarme, werden von der Mediationsfunktion in Alarme von 
funktionalen, Gesamtausstattung s-Managementobjekten 
umgewandelt und anschlieBend in Form von hersteller-un- 
abhangigen Alarmberichten an das Netzmanagementzen- 
trum NMC weitergeieitet. Die urspriingliche hardware-be- 

35 zogene Alarmmeldung wird gemaB ITU-T X.733 ("Systems 
Management: Alarm Reporting Function") in eine funktio- 
nale, standardisierte Alarmmeldung mit z. B. folgenden Pa- 
rametern "gemapped" bzw. abgebildet: 

40 - Objektklasse: btsEquipment (modelliert die Funktio- 
nalitat der Hardware in einer Netzeinheit BTSE) 

- Objektinstanz: ... -8. 

Hinsichtlich der Objektinstanz gibt es an der OMC- 

45 NMC-Schnittstelle eine 1 : 1-Zuordnung zwischen den tat- 
sachlichen Netzeinheiten BTSE und den funktionalen, gene- 
rischen Instanzen der Objektklasse btsEquipment. 

Beim in Fig. 2 dargestellten Beispiel wird die zum Be- 
triebs- und Wartungszentrum OMC iibertragene ursprungli- 

50 che Alarmmeldung mit "MOC = TPU" und "MOI = 1" auf 
eine abgebildete Alarmmeldung mit den Informationen 
"MOC = btsEquipment", "MOI = 8" und "Zusatzinforma- 
tion (standardisierter Parameter "Additional information") = 
[rack 2, TPU 1]" abgebildet. 

55 Die hersteller-spezifische Information, die die urspriingli- 
che fehlerhafte Hardware eindeutig kennzeichnet, wird von 
der Mediationsfunktion somit im Feld Zusatzinformation 
definiert. Die Zusatzinformation der an das Netzmanage- 
mentzentrum NMC gesendeten Alarmmeldung ist beim vor- 

60 liegenden Beispiel gemaB dem Standard ITU-T X.710 
"Open Systems Interconnection - Common Management 
Information Service Definition" wie folgt definiert: 

- Rack-Nummer: 2, weil die BTSE-Hardware hier in 
65 mehreren Racks untergebracht ist, 

- Board-Typ: TPU und 

- Board-Nummer: 1. 
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Nach dem Empfang des mediierten Alarmberichts er- 
kennt die NMC-Software des Netzmanagementzentrums 
NMC anhand der Objektklasse ("equipment- summary" 
btsEquipment), da6 es sich hier urn einen hersteller-spezifi- 
schen Hardwarefehler handelt 

Um den Fehler naher zu untersuchen, d. h. festzustellen, 
ob es ein transienter oder ein permanenter Fehler ist, ob das 
Board ersetzt werden soli etc., muB das Netzmanagement- 
zentrum NMC einen fur das aktuelle Board (TPU) spezifi- 
schen Test starten. Dies sollte vorzugsweise automatisch er- 
folgen. Dafur wertet die NMC-Software das Feld "Zusatzin- 
formation" aus und kann, zusammen mit der Objektklasse 
und -instanz der mediierten Alarmmeldung, die Adresse des 
fehlerhaften Board eindeutig bestimmen und nachbilden. 

Damit generiert das Netzmanagementzentrum NMC, wie 
in Fig. 3 skizziert, eine gemaB ITU-T X.745 (Systems Ma- 
nagement: Test Management Function) standardisierte Ma- 
nagementaktion "M- ACTION", in der die zu testende Hard- 
ware mit Hilfe der sogenannten "nonSpecificForm" definiert 
ist. Parameter ist dabei das Feld "toBeTestedMOKTs" bzw. 20 
zu testende Boards. Beim vorliegenden Beispiel definiert 
das 1. Byte die Gestell- bzw. Rack-Nummer, in dem sich das 
zu testende Board bzw. eine zu testende Leiterplatte befin- 
det. Das 2. Byte definiert den Board-Typ, d. h. im vorliegen- 
den Beispiel TPU und das 3 . Byte definiert die Leiterplatten- 25 
bzw. Board-Nummer, hier 1. 

Die Managementaktion M- ACTION wird von dem Netz- 
managementzentrum NMC uber die Schnittstelle an das Be- 
triebs- und Wartungszentrum OMC gesendet, wobei der 
Empfanger immer ein Managementobjekt vom Gesamtaus- 30 
stattungstyp ("equipment-summary" object) ist. Dies ist im 
vorliegenden Fall die btsEquipment-Instanz 8. 

Im Betriebs- und Wartungszentrum OMC wandelt die 
Mediationsfunktion diese Managementaktionsanforderung 
(M-ACTION Request) in eine Test-Anforderung gemaB 35 
dem hersteller-spezifischen Informations-Modell der OMC- 
BSS-Schnitts telle um. Anhand der 1 : 1-Zuordnung zwi- 
schen der realen Basisstations-Empfanger-/Senderstations- 
Einrichtung BTSE und der Gesamtausstattungs-Instanz 
btsEquipment und dem Parameterwert "toBeTested- 40 
MORTs", kann die Mediationsfunktion die Adresse des zu 
testenden Boards im realen Telekommunikationsnetz ein- 
deutig definieren. Die Test-Anforderung enthalt dabei vor- 
teilhafterweise auch die Kennung des fur das aktuelle Board 
vordefinierten, hersteller-spezifischen Tests. 45 

Die von der Netzeinheit, hier BTSE 8, zuriickgesendeten 
Testergebnisse werden von der Mediationsfunktion im Be- 
triebs- und Wartungszentrum OMC wiederum gemaB dem 
Informations-Modell der OMC-NMC-Schnittstelle umge- 
wandelt und mit der vorherigen NMC-Test-Anforderung des 50 
Netzmanagementzentrums NMC mit Hilfe des standardi- 
sierten Parameters "Testaufruf-ID" bzw. "testlnvocationld" 
eindeutig korreliert. Dabei sendet das OMC nach dem stan- 
dardisierten NMC-Testkommando eine "Response", die den 
Parameterwert "testlnvocationld" enthalt, damit ein Test- 55 
vorgang eindeutig gekennzeichnet ist. Der gleiche Wert 
wird vom Betriebs- und Wartungszentrum OMC nach Te- 
stende in die testResultNotification fur das Netzmanage- 
mentzentrum NMC eingefiigt. 

Die abgebildeten bzw. mediierten Testergebnisse konnen 60 
von der NMC-Software auch zur automatischen Erstellung 
von sogenannten Fehlerformularen bzw. "Trouble tickets" 
verwendet werden, damit entsprechende ReparaturrnaBnah- 
men vor Ort eingeleitet werden konnen. 

Die Definition der OMC-NMC-Schnittstelle ermoglicht 65 
zusatzlich und/oder alternativ auch die automatische Gene- 
rierung von periodischen, praventiven Hardware-Tests an 
dem Netzmanagementzentrum NMC. In der gemaB ITU-T 
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X.745 standardisierten Test-Anforderung kann das Netzma- 
nagementzentrum NMC einen speziellen Wert fur das zu te- 
stende Board im Attribut "toBeTestedMOKTs" verwenden. 
Die Mediationsfunktion kann dieses Xommando z. B. als 
5 Test-Anforderung fur jene gesamte Netzeinheit interpretie- 
ren, die vom Empfanger der Test-Anforderung modelliert 
wird. Im vorliegenden Beispiel ist dies die btsEquipment- 
Instanz 8. Demzufolge erzeugtdie Mediationsfunktion meh- 
rere einzelne, fur jedes Hardware-Board spezifische Test- 
10 kommandos, die an die Netzeinheit BTSE 8 hintereinander 
gesendet werden. 

Nach jedem Test werden die einzelnen Testergebnisse 
von der Mediationsfunktion gesammelt, "gemapped" und 
als eine gemaB ITU-T X.745 standardisierte Testergebnisse- 
15 Benachrichtigung bzw. sogenannte "testResultNotification" 
das ubergeordnete Netzmanagementzentrum NMC uber- 



Patentanspriiche 

1. Verfahren zum Verwalten eines Kommunikations- 
netzes mit 

- zumindest einer ubergeordneten funktionalcn, 
insbesondere hersteller-unabhangigen Einrich- 
tung (NMQ und 

- zumindest einer davon uberwachten und/oder 
gesteuerten untergeordneten Einrichtung (OMC), 

- zwischen denen Nachrichten iiber den Zustand 
zumindest einer nicht funktionalen, insbesondere 
hersteller-abhangigen Einrichtung (OMC, BSC, 
BTSE, TRAU) des Kommunikationsnetzes aus- 
getauscht werden, dadurch gekennzeichnet, daB 
beim Austausch einer Nachricht zumindest eine 
nicht funktionale, insbesondere hersteller-abhan- 
gige Information ubermittelt wird. 

2. Verfahren nach Anspruch 1, bei dem die Nachricht 
mit der hersteller-abhangigen Information zyklisch 
und/oder auf Anforderung und/oder nach einem Fehler 
in der zumindest einen hersteller-abhangigen Einrich- 
tung (OMC, BSC, BTSE, TRAU) ubermittelt wird. 

3. Verfahren nach Anspruch 1 oder 2, bei dem die 
Nachricht an die hersteller-unabhangige ubergeordnete 
Einrichtung (NMC) ubermittelt wird. 

4. Verfahren nach einem vorstehenden Anspruch, bei 
dem mit der Nachricht eine hersteller-abhangige Infor- 
mation uber den Zustand zumindest einer bestimmten 
hersteller-abhangigen Einrichtung (OMC, BSC, BTSE, 
TRAU) ubermittelt wird. 

5. Verfahren nach einem vorstehenden Anspruch, bei 
dem in der untergeordneten Einrichtung (OMC) eine 
Umwandlung der hersteller-abhangigen Information zu 
einer hersteller-abhangigen Zusatzinformation fur die 
hersteller-unabhangige Nachricht an die hersteller-un- 
abhangige ubergeordnete Einrichtung (NMC) durchge- 
fuhrt wird. 

6. Verfahren nach Anspruch 1 oder 2, bei dem eine 
Nachricht, insbesondere Test-Anforderungsnachricht 
mittels der hersteller-abhangigen Information von der 
hersteller-unabhangigen ubergeordneten Einrichtung 
(NMC) aus zu einer oder mehreren bestimmten der 
hersteller-abhangigen Einrichtungen (OMC, BSC, 
BTSE, TRAU) ubermittelt wird. 

7. Verfahren nach Anspruch 1, 2 oder 6, bei dem durch 
die Ubermittlung der Nachricht der Zustand zumindest 
einer hersteller-abhangigen Einrichtung (OMC, BSC, 
BTSE, TRAU) uberpruft oder abgefragt wird, insbe- 
sondere herstellerspezifische Tests aktiviert werden. 

8. Verfahren nach einem vorstehenden Anspruch, bei 
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dem in der untergeordneten Einrichtung (OMC) eine 
e Umwandlung einer hersteller-abhangigen Zusatzinfor- 
mation der hersteller-unabhangigen Nachricht zu einer 
hersteller-abhangigen Information fiir die hersteller-ab- 
hangige Einrichtung (OMC, BSC, BTSE, TRAU) 5 
durchgefiihrt wird. 

9. Verfahren nach einem vorstehenden Anspruch, bei 
dem die Information als Zusatzinformation, mittels ins- 
besondere standardisierter Nachrichten ubermittelt 
wird. 10 

10. Verfahren nach einem vorstehenden Anspruch, bei 
dem uber eine Schnittstelle zwischen der zumindest ei- 
nen hersteller-unabhangigen iibergeordneten Einrich- 
tung (NMC) und der zumindest einen untergeordneten 
Einrichtung (OMC) die Nachrichten gemaB einem In- 15 
formations-Modell der Schnittstelle (OMC-NMC) 
ubermittelt werden, wobei das Informations-Modell 
nicht fiir hersteller-abhangige Informationen ausgelegt 
ist. 

11. Verfahren nach Anspruch 10, bei dem das Informa- 20 
tions-Modell objektorientiert aufgebaut ist und keine 
hersteller-abhangigen Objektklassen kennt. 

12. Verfahren nach einem vorstehenden Anspruch, bei 
dem die hersteller-abhangige Information als Zusatzin- 
formation in einer ublichen, insbesondere standardi- 25 
sierten Nachricht ubermittelt wird. 

13. Kommunikationssystem, insbesondere Funk- 
Kommunikationssystem, zum Durchfuhren eines vor- 
stehenden Verfahrens. 

14. Kommunikationssystem nach Anspruch 13, bei 30 
dem die hersteller-unabhangige ubergeordnete Einrich- 
tung (NMC) ein Netzmanagementzentrum ist. 

15. Kommunikationssystem nach Anspruch 13 oder 
14, bei dem die zumindest eine untergeordnete Einrich- 
tung ein Betriebs- und Wartungszentrum (OMC) von 35 
einer aus insbesondere einer Vielzahl von Netzregio- 
nen ist. 
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Fig. 2 



NMC 



Abgebildeter Alarm bericht 

- MOC: btsEquipment 

' MOI: 8 

- Zusatzinformation: [rack 2, TPU, 1] 




Original-Alarmbericht 

-MOC: TPU 
- MOI: 1 




BTSE8 



Fig. 3 



NMC 



Test-Kommando (ITU-T X.745 , X.710) 

- MOC: btsEquipment 
- MOI: 8 

toBeTestedMO RTs: frack 2 TPU 1] 




Testa nforderung 

- MOC: TPU 
- MOI: 1 




BTSE8 



l 4 i-W] 



_..Rack2 

^ w 1 
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